Method and system for performing a transaction and for performing a verification of legitimate access to, or use of digital data

ABSTRACT

A method for performing an electronic transaction is disclosed. The method provides authentication data and authentication software to an electronic device and preferably stored in a secure storage location or other location inaccessible to the user or the operating system of the device. The authentication software is activated to generate a digital signature from the authentication data. Next, the digital signature is provided to the other transaction party.

The present invention relates to a method and system for performing anelectronic transaction and for performing a verification of legitimateaccess to, or use of digital data.

At present, numerous transactions are being handled by electronic meansin digital format. Digital networks have evolved which enable parties ofdifferent kind across the world to communicate with each other and toexchange data and information to reach desired transactions.

The data and information exchanged in said transactions may be legallyprivileged or protected by copyright, for example. However, digitalinformation may be very easily copied and spread without a trace of whoillegally copied and spread the data.

Further, in particular in transactions involving private network access,financial commitments, settlements and/or payments, each party involvedin such a transaction wants to identify any other party, or at least, tobe able to track any other party, if after completion of the transactiona problem arises. For such identification purposes, it is known to usepersonal identifiers, such as passwords, Personal Identification Numbers(PIN), and the like, which are only known to a specific user. However,using personal identifiers over public networks like the Internet, thereis a possibility that the personal identifier becomes known to anotherperson, enabling this other person to do transactions or gain access todigital data presenting himself as somebody else. If a problem arisesafter completion of the transaction, it is not possible to track thereal transaction partner, as its personal identifier may have been usedby a malicious user of the public network.

For a more secure transaction, it has been proposed in European PatentApplication No. 1 219 088 to use a trusted third party transactionserver comprising profiles of the transaction parties. The transactionserver verifies the identity of the transaction parties by usingauthentication data comprising a table of random data for verifying adigital signature. The digital signature is generated from a randomtoken using a token reader. The table of random data corresponds to datacollected from said random token. Thus, a digital signature originatingfrom the random token and being different for every subsequenttransaction is virtually impossible to forge and therefore uniquelyidentifies the transaction party.

A disadvantage of this system and other systems employing additionalhardware is that the additional hardware, e.g. a token and a tokenreader, should be supplied to every possible transaction party.

It is therefore an object of the present invention to provide a methodand system for performing an electronic transaction or electronicverification or identification without requiring additional hardware.

At least this object is achieved in the present invention by a methodfor performing an electronic transaction between a first transactionparty and a second transaction party using an electronic device operatedby the first transaction party. The method comprises providingauthentication data in a memory of said electronic device, whichauthentication data are inaccessible to a user of the electronic device;providing authentication software in said electronic device, theauthentication data being accessible to said authentication software;activating the authentication software to generate a digital signaturefrom the authentication data; providing the digital signature to thesecond transaction party. In a preferred embodiment, the secondtransaction party provides digital data to the first transaction party.

In a further aspect, the present invention provides a method forperforming a verification of legitimate use of digital data on anelectronic device. The method comprises providing authentication data ina memory of said electronic device which authentication data areinaccessible to a user of the electronic device; providingauthentication software in said electronic device, the authenticationdata being accessible to said authentication software; activating theauthentication software to generate a digital signature from theauthentication data; providing the digital signature to an applicationwhich accesses digital data having a digital signature embedded therein;and comparing the digital signature embedded in the digital data withthe provided digital signature.

In another aspect, the present invention provides a method forencrypting digital data on an electronic device using an encryption key,the method comprising gathering session specific data; hashing saidsession specific data to obtain reference numbers referring to positionsin an authorization table stored in said electronic device; generatingsaid encryption key from the characters stored in the authorizationtable at said positions; and encrypting said digital data using saidencryption key.

In a further aspect, the present invention provides systems forperforming said methods.

Without use of any additional hardware, a transaction party in anelectronic transaction may be identified with virtually no possibilityfor fraudulent use of the method. In a private network accesstransaction, the first transaction party is uniquely identifiable by itsdigital signature. Said digital signature is provided to the secondtransaction party that may store the digital signature. If a problemarises later, the first transaction party may be traced and identifiedby the digital signature provided to the second transaction party.

If digital data are provided to the first transaction party, e.g.copyright protected files such as music and the like, that are digitallysigned according to the present invention, i.e. a digital signature isembedded in the digital data, said digital data may be traced, if theyare later found to be illegally copied or spread. The embedded digitalsignature is uniquely traceable to the original first transaction partythat received said digitally signed digital data.

Digital data digitally signed according to the present invention arestored in a storage medium of a device having the authenticationsoftware installed. The signature has been generated in accordance withthe authentication data stored in said device and thereafter embedded inthe digital data to protect the data and to be able to trace a malicioususer.

The signature embedded in the data may also be employed to prevent thatthe data are illegally used, since the signature may be regenerated bythe device at any time. As a regenerated signature should be identicalto the one embedded in the digital data, a comparison of the embeddedsignature with the regenerated signature provides information whetherthe digital data is rightfully installed on the device. If thecomparison shows that the signatures are identical, the data may beaccessed by the device, and, for example, an application comprised insaid digital data may be run or said digital data may be accessed by anyother application, for example for playing music represented by saiddigital data. When the signatures are not identical, the digital dataare illegally installed, e.g. copied from another device, and they maynot be accessed and read by the device and an error signal may begenerated.

Further aspects and features of the present invention are disclosed inthe dependent claims.

The invention and its aspects, features, and advantages will be morereadily appreciated as the same becomes better understood by referenceto the following detailed description and considered in connection withthe accompanying drawings provided by way of non-limiting examples, inwhich drawings like reference symbols designate like actions or parts.

FIG. 1 illustrates a chart of an installation method for a new deviceaccording to the present invention.

FIG. 2 illustrates a chart of an installation method for an existingdevice according to the present invention.

FIG. 3 schematically illustrates a computer configuration havingauthentication software and an authentication table installed in theBIOS according to the present invention.

FIG. 4 illustrates a chart of another installation method for anexisting device according to the present invention.

FIG. 5A schematically illustrates a computer configuration havingauthentication software and an authentication table installed in a useraccessible memory.

FIG. 5B schematically illustrates a memory location secured by twoencryption layers.

FIG. 6 illustrates a chart of a method to generate a digital signaturefrom a random table.

FIG. 7 illustrates a chart of a method to generate a personalizedtraceable digital file according to the present invention.

FIG. 8 illustrates a chart of an off-line authentication of digitalrights according to the present invention.

FIG. 9 illustrates a chart of an on-line authentication or transactionmethod according to the present invention.

FIG. 10 illustrates a chart of an off-line authentication of digitalrights of digital data stored in a removable memory according to thepresent invention.

Referring to FIGS. 1, 2, 4 and 6-9, in the methods illustrated in therespective Figures actions of different actors are shown in a number ofcolumns. In the vertical direction, actions of the actors have beenarranged in an essentially chronological order from top to bottom. Thus,actions described in one row of a chart essentially are performed priorto actions in a subsequent (lower) row of the chart, although this maynot always be necessary, as indicated in some instances. The arrows inthe Figures indicate a flow of data, which may be transferred through asuitable connection, such as a hard-wired connection, or a wirelessconnection, or a combination thereof, using an appropriate protocol in anetwork connection.

In this context, an installation method is to be understood as a methodfor installing software at some actors involved in the present methodfor enabling tracking and tracing of at least one transaction party.Further in this context, a new device relates to any electronic devicecontaining a Basic In Out System (“BIOS”, “Boot agent” etc.) with anyassociated secure storage/memory location, e.g. a computer, server,printer, personal digital assistant, mobile telephone, which is beingmanufactured, or has been manufactured, but has not yet been deliveredto an end-user, whereas an existing device relates to any electronicdevice containing a Basic In Out System which has been delivered to anend-user, and may or may not have been used by the end-user. The BasicIn Out System is only referred to as a system for accessing a memorylocation in a memory that is directly or indirectly connected to theelectronic device. However, as is described hereinafter, the methodaccording to the present invention may employ such a BIOS system tosecurely store certain digital data and/or such a BIOS system may beprovided with an encryption system. A secure storage location and/or anencryption system are not essential to the BIOS system with respect tothe present invention.

FIG. 1 illustrates a first preferred embodiment of the presentinvention. Referring to FIG. 1, an installation method for a new deviceis illustrated. The method of FIG. 1 includes five actors: a randomtable supplier, a trusted third party, a BIOS manufacturer, a BIOS andauthentication software. The first, second and third actors are physicalentities, e.g. persons or companies, whereas the fourth and fifth actorsare software embedded in a device.

In the first column of FIG. 1 actions of the random table supplier areshown. This supplier generates and supplies a random table or,essentially, random data to another actor.

A random table is defined as a table comprising random numbers. Such atable may be created by suitable software as such. Alternatively, U.S.Pat. No. 5,354,097 discloses another method of producing random numbersby optically scanning a randomly shaped material, such as a non-wovenmaterial. Likewise, a two-dimensional pattern may be used, which patternhas been formed by transformation of a bit string as disclosed inEuropean Patent Application No. 1,219,088. From data collected duringthe reading of the randomly shaped material or pattern, random numberscan be derived, e.g. by using a predetermined algorithm.

The second column of FIG. 1 relates to actions of a trusted third party(TTP), which may be selected by the random table supplier, a BIOSmanufacturer and/or the owner of any application or service. The TTPgenerates a bit string from the random table and other data, to beelucidated below. Further, the TTP stores the bit string and other dataused to generate it. The generated bit string is sent to the BIOSmanufacturer.

It is noted that in another embodiment of the present invention, the bitstring may be generated and stored by another actor than the TTP. Forexample, in case of network access identification, the networkadministrator and/or a network server may generate and store the bitstring such that when a user attempts to access the private network, thenetwork administrator or server may regenerate the digital signature ofsaid user. Thus, the user may unambiguously be identified by the networkadministrator or server before the user is granted access to thenetwork.

The actions of the BIOS manufacturer are represented in the third columnof FIG. 1. The BIOS manufacturer installs authentication software in aBIOS and stores the bit string supplied by the TTP in the BIOS.

The BIOS which is supplied by the BIOS manufacturer, is also an actor inthe method, and its actions are represented by the fourth column ofFIG. 1. The BIOS may be coupled to the TTP to receive a decryption codeand enable the authentication software to decrypt an authenticationtable, which will then be encoded again and stored in a secure part ofthe device, only accessible to the BIOS.

The fifth column of FIG. 1 represents the actions of the authenticationsoftware, which may be supplied by the random table supplier or by anyother third party and is stored in the BIOS. The authentication softwaremay be coupled to the TTP to decrypt the bit string in the BIOS into anauthentication table, encrypts the authentication table again and storesit in the secure part of the device, only accessible to the BIOS.Further, the authentication software stores and activates adigital-signing algorithm to generate a session- or transaction-specificdigital signature. The authentication software preferably runs in aseparate operating environment in the BIOS or in a console and isindependent from and inaccessible to the operating system (OS) on thedevice.

As indicated in FIG. 1, the installation method for a new device for usewith the tracking and tracing method according to the present inventionstarts with the generation of a random table, e.g. a table comprisingrandomly chosen characters or numbers, according to cell 2. The numbersmay be generated using software employing an algorithm. Alternatively,as disclosed in U.S. Pat. No. 5,354,097, random numbers may be deducedfrom a randomly shaped material, such as a non-woven material. Forexample, in a non-woven material, fibers are arranged in a random orderdue to the randomness of the production process. From the geometry ofthe fibers of the non-woven material numbers may be calculated. Forexample, a number that may be calculated, may be the angle between twofibers in an area of the material, or the number of fibers crossing animaginary line. The calculated numbers will be random, as the geometryof the material is random. Another alternative manner, as disclosed inEuropean Patent Application No. 1,219,088, to collect random numbers isby transforming a bit string into a two-dimensional pattern using analgorithm. As described above from this two-dimensional pattern a tableof random numbers may be calculated based on the geometry of thepattern.

The random table supplier may generate the random table and supply it tothe TTP. Alternatively, the random table supplier may only supply apiece of non-woven material or software to generate two dimensionalpatterns according to European Patent Application No. 1,219,088, fromwhich the TTP may then generate one or more random tables.

According to cell 4, a BIOS manufacturer embeds or installsauthentication software in the BIOS. The authentication software may besupplied by the random table supplier, generated by the BIOSmanufacturer or supplied by a third party.

The authentication software preferably has its own unique serial number,software ID and/or private encryption key. Said unique number may beadvantageously employed in the installation method and in a track andtrace method, as explained below.

Further, according to cells 6A-6E, the TTP generates a unique bitstring, in the following way. First, according to cell 6A, the TTPcollects fixed data, such as a unique serial number from a hardwaredevice, a processor for example, or the unique software ID embedded inthe authentication software in the previous step.

Preferably, the fixed data refer to a number or other character stringstored in or related to the specific BIOS. The bit string, which will begenerated from the fixed data, among others, is preferred to have astrong relation with the BIOS in which it is stored. Such a strongrelation makes forging the bit string difficult.

In the next step 6B, the TTP selects a random table previously receivedfrom the random table supplier, or it generates a random table using amarker, such as a piece of non-woven material or using a random twodimensional pattern.

The TTP further generates a data string according to cell 6C. The threedata sets, e.g. the fixed data, the random table and the data string,are used to generate a bit string using a predetermined algorithmaccording to cell 6D. The bit string is stored in a database accordingto cell 6E together with the fixed data and the data string, which wereused to generate it.

The bit string is supplied to the BIOS manufacturer, preferably in anencrypted way. The BIOS manufacturer embeds the bit string, like theauthentication software, in the BIOS according to cell 8. At this point,a computer may be assembled having a BIOS which comprises authenticationsoftware and a bit string. Thereafter, the computer may be sold,installed and connected to a network, such as the Internet.

At the first start-up of the computer according to cell 10 the BIOS orthe authentication software uses a connection to a network, such as theInternet, to establish a connection with the TTP. The connection isbeing made to collect the data string, which is needed to decrypt thebit string and generate an authentication table. The BIOS or theauthentication software may be identified by the TTP using the fixeddata, which is a unique number as mentioned above.

The connection with the TTP does not need to be initiated by the BIOS,but may also be initiated by the authentication software, which isembedded in a secure part of the BIOS, or by a third party application.The connection preferably is made without a possibility for a user orthe operating system of the computer to interrupt the procedure.

When a connection with the TTP is established, the BIOS orauthentication software sends its identification number upon request ofthe TTP according to cell 12. The TTP returns, possibly upon request ofthe BIOS, the decrypt key, and the authentication software uses thedecrypt key according to cell 14 to generate an authentication tablefrom the bit string which was embedded in the BIOS according to cell 8.

Next, according to cell 16, the authentication table is encoded by theauthentication software to prevent that the authentication table may beuncovered (e.g. by a person). Uncovering of the authentication tablewould weaken the protection conferred by the method and should thereforebe virtually impossible.

The encoding is performed using a number, which is specific for theBIOS. When the authentication table is needed later, it may then bedecoded by the authentication software using that BIOS-specific number.The BIOS-specific number may be a unique serial number or any ordinaryencryption key incorporated in or generated by the BIOS, for example.The BIOS-specific number is sent to the authentication softwareaccording to cell 18 after a request from the authentication softwareaccording to cell 16.

The installation in a new device is completed according to cell 20. Theencoded authentication table is stored in a secure part of the BIOS,where it may only be retrieved by the BIOS and not by the operatingsystem. This secure part of the BIOS may also be any other, securelocation in the device. For instance, it may be a separate part of ahard drive of a computer, which part may not be accessible to theoperating system, but only to the BIOS and/or authentication software.Storing the authentication table in a secure location further decreasesthe possibility of retrieval of the authentication table.

The device is now set-up. Authentication software and an encodedauthentication table are installed in the BIOS. Further, in a databaseof a trusted third party (TTP), data are stored which enable the TTP togenerate the same authentication table when later needed.

FIG. 2 illustrates a second preferred embodiment. In the secondpreferred embodiment, the installation method is performed on anexisting computer device. The existing device does not haveauthentication software installed in its BIOS, nor does it have anencrypted bit string stored in its BIOS at the time a digital signatureaccording to the present invention is needed for any track and tracepurpose, including a particular electronic session, e.g. a networkaccess procedure, or an on-line transaction. Thus, compared to a newcomputer device, further steps are necessary in the above-describedinstallation method to install the necessary software and authenticationtable in a secure memory location of the device. Such a secure memorylocation may be a part of a secure memory or it may be an encrypted partof a non-secure memory, such as a user-accessible memory.

In FIG. 2, there are five columns representing five actors: a randomtable supplier, a TTP, a BIOS, authentication software and a third partyapplication. Compared to FIG. 1 the BIOS manufacturer is no actor in theinstallation method for an existing device, but a third partyapplication is introduced as an actor. The third party application is anon-line application, usually intended to do on-line logical access, oron-line transactions. The third party application requests a digitalsignature from the existing device, which does not have theauthentication software and the authentication table. The third partyapplication therefore requests that the device installs theauthentication software first before continuing the transaction.

According to cell 22, the random table supplier generates and supplies arandom table, similar to the action according to cell 2 in FIG. 1.

According to cell 24, a device having a BIOS without an authenticationtable and/or authentication software initiates an on-line transactionwith a third party application. The third party application, however,requires an authentication according to the present invention.Therefore, the third party application redirects the requesting deviceto the TTP to obtain the authentication software and an authenticationtable.

The TTP generates and stores a bit string according to cells 26A-26E,similar to cells 6A-6E of FIG. 1. According to cell 26A the TTP collectsfixed data, according to cell 26B a random table or a random marker isselected, and according to cell 26C the TTP selects a data string. Fromthese three data sets, the TTP generates a bit string according to cell26D and stores the bit string, the fixed data and the data stringaccording to cell 26E. Further, the bit string is sent to the requestingdevice together with the authentication software, both encrypted.

The authentication software and the bit string are put in a part of theBIOS which is accessible to the operating system according to cell 28A.Next, according to cell 28B, the device needs to reboot to store theauthentication software and the bit string in a secure part of the BIOSwhich is not accessible for the operating system.

At this point, the method continues as the method illustrated in FIG. 1from cell 10 and further. According to cell 30 the device having newlystored authentication software and a bit string in its BIOS contacts theTTP again and requests a decrypt key, for example the data string,according to cell 32.

According to cell 34, the decrypt key is used to decrypt theauthentication software and to decrypt the bit string and generate thecorresponding authentication table. Next, according to cell 36, theauthentication software verifies the authentication table and requestsBIOS-specific data from the BIOS to encrypt the authentication tableagain.

According to cell 38 the BIOS sends BIOS-specific data, for example anycommon encryption key, to the authentication software in reply. Themethod is completed according to cell 40, wherein the authenticationtable is encrypted and stored in a secure part of the BIOS. Any dataremaining in the operating system from the transfer of theauthentication data and authentication software is deleted by the BIOS.

Using this installation method every device having a BIOS and capable ofcommunicating with external, third party applications may have theauthentication software and an authentication table installed, forexample a personal computer, a cellular phone, a hand-held personaldigital assistant with wireless communication capabilities or any otherdevice containing a BIOS, as mentioned above.

When the software and the table are correctly installed in the BIOS,particular sessions, track and trace or on-line transactions may beinitiated and performed using the authentication and digital signingmethod.

FIG. 3 schematically illustrates a possible configuration of a devicehaving the authentication software and an authentication tableinstalled. The device consists of several components, commonly referredto as hardware 42. Exemplary hardware components are a processor, a harddrive, or other memory and a keyboard.

All the hardware devices are controlled by the BIOS 44. The BIOS 44 is asoftware package stored in a read-only memory (ROM), usually located ona main board, which is one of the hardware components of an electronicdevice.

The BIOS 44 controls most of the instructions and data flowing from onecomponent to another. Data or instructions coming from one component andaddressed to another need to pass through the BIOS 44. The BIOS 44 maycheck whether the instructions to the other component are allowed ornot, as not every component is accessible for any other component.

The BIOS 44 may comprise an encryption key 46. Such an encryption key 46may be used to encrypt data and only another party who knows theencryption key 46 may be able to decrypt the data.

The operating system 48 creates a run-time environment for any userapplications. Therefore, it may be stated that the operating system 48is an interface between a user and the hardware 42. A user may instructthe operating system 48 to run an application 50. If the application 50needs data that are stored on the hard drive, the application 50requests the data from the operating system 48. The operating system 48in turn requests the data through the BIOS 44 from the hardware 42, i.e.the hard drive. The data coming from the hardware 42 pass through theBIOS 44 and the operating system 48 before they arrive at the requestingapplication 50. Via this protocol the BIOS 44 may control theaccessibility of certain data or hardware devices 42 and thus the use ofparticular software. It may prohibit, for example, the operating system48 to access certain parts of a hard drive or start certainapplications.

A console 52 is an environment, which runs all the processes in thecomputer without user interruption. The console 52 plays an importantrole at start-up of the computer, instructing the hardware devices 42via the BIOS 44 to start and report their status. In case of errors, notonly at start-up but also during operation, the BIOS 44 sends the errormessages coming from the hardware 42 to the console 52. The console 52then handles and corrects the errors. Thus, the console 52 runs more orless stand-alone the computer. A user may not interrupt or influence theconsole 52. Any instructions coming from the operating system 48intended for the console 52 may therefore be blocked by the BIOS 44.

In or behind the console 52, there is a secure area 62 only accessibleto the BIOS. The secure area 62 comprises applications and storagelocations, which are not reported to the operating system 48. That meansthat the operating system 48 does not know that the applications anddata in the storage locations are present and maybe even running in aseparate environment. For example, when a hardware device 42 reports anerror, the console 52 may run a recovery application 56 to handle theerror such that the hardware device 42 recovers from the error and isable to continue its operation. The operating system 48 has probably noteven noticed that there was an error.

An authentication table may be securely stored in the secure storagelocation 60. In such a part of the computer, commonly seen as a part ofthe BIOS 44, the authentication table is unreachable for the operatingsystem 48 and thus for a user.

With the authentication table securely stored in the secure storagelocation 60, the authentication software 54 should run in an environmentin the BIOS 44, thus preventing that the authentication table isaccessible to the operating system 48 at any time. Therefore, theauthentication software 54 may be installed in an applicationenvironment in the secure area 62 such that it may obtain theauthentication table without passing through an unsecured part of thedevice.

The secure area 62 may further comprise other applications and/or memorylocations. For example, another memory location 58 may store a log fileof all actions performed by the BIOS 44 in the secure area 62, or a logfile storing any other actions by any other application or all networkdata exchange, for example all data exchanges over the Internet.

Further, the digital signing algorithm is preferably stored in a securepart of the BIOS 44. This algorithm may be protected like theauthentication table in the secure storage location 60, because if bothbecome known to a user, the user may be able to forge a digitalsignature. By locking the authentication table and the authenticationsoftware 54 including the digital signing algorithm in the secure area62 they are secured.

In a third preferred installation method illustrated in FIG. 4, theauthentication data, e.g. authentication table, is stored in a memorythat is accessible to an operating system of the device and possibly toa user of said device. To prevent that the user may obtain theauthentication data, which should be prevented as described above, theauthentication data are encrypted. Thus, the user may only obtainencrypted authentication data. To prevent that the authentication databecomes accessible to a user, the authentication data should only bedecrypted in a secure processing environment such as a ‘Ring Zero’processing environment, which is embedded in a processing unit ofcommonly used personal computers. Such a secure processing environmentmay only be accessible to selected software applications, preferably notto user-operated software applications. Further, a decryption algorithmand/or a decryption key should not be obtainable to any user.

It is preferred to encrypt the authentication data twice, i.e. using atleast two encryption layers. If a malicious user succeeds in decryptingthe authentication data once, thus succeeds in decrypting a firstencryption layer, a second encryption layer still protects theauthentication data.

Preferably, a first encryption layer uses an encryption algorithmemploying a device specific encryption key, for example an encryptionkey associated with part numbers of one or more parts of the device. Asecond encryption algorithm employs preferably an encryption layerassociated with supplied data, such as a supplied bit string or asupplied encryption algorithm. Therefore, the third preferred embodimentis especially suitable for use with an electronic device previouslyprovided with an encryption system for encrypting data using a devicespecific encryption key. Such devices are known in the art and arecommonly and commercially available. In FIG. 4, the third preferredembodiment is illustrated in relation to such a device.

FIG. 4 shows two actors in the installation method. A first actor is athird party application. The third party application may be anapplication for performing an electronic transaction that needsauthentication data, and if no authentication data are found on thedevice, initiates an installation of the authentication software. Also,it may be an application or an operating system controlled by a user toinitiate an installation of the authentication software. The secondactor in the installation method is the authentication software. Themethod may be extended with a third actor. For example, the BIOS may beenabled to encrypt data using a device specific encryption key. In sucha case, the BIOS may generate an encryption layer according to cell 210or 212, as will be described hereinafter.

Now referring to FIG. 4, the third preferred installation methodaccording to the present invention starts with obtaining and installingan authentication software package, for example obtained through theInternet, as indicated in cell 200.

After installation of the authentication software, the authenticationsoftware obtains a master bit string (MBS) according to cell 202. Themaster bit string (MBS) may be a large array of characters, for example2048 numbers. The MBS may be embedded in the authentication softwarepackage, and may in that case not need to be obtained separately asindicated in FIG. 4.

From said master bit string (MBS), according to cell 204, theauthentication software selects a bit string. Said bit string thuscomprises a number of said characters, for example 128 charactersrandomly selected from the MBS.

The authentication software generates authentication data, e.g. anauthentication table, from the bit string in accordance with cell 206.The authentication software runs in the above-mentioned secureprocessing environment. Thus, the algorithm generating theauthentication data from the bit string is protected against malicioususers who want to obtain the authentication data or said algorithm.

The authentication data are generated from a bit string that isgenerated at the device of the first transaction party and the bitstring and is therefore not known to a second transaction party or atrusted third party (TTP). Thus, the second transaction party cannotgenerate and store (a copy of) the authentication data. Foridentification of the first transaction party in a transaction, theauthentication data need to be known to the second transaction party ora TTP. Therefore, if the authentication data are to be used foridentification in a transaction, a copy of the bit string is returned tothe supplier of the authentication software package or to another party,which party may be a second transaction party or a TTP in accordancewith cell 208.

The bit string may be encrypted or not, while it is returned to theother party. If it is ensured that the algorithm for generating theauthentication data from said bit string is not known to any user, theactual bit string used for generating the authentication data may becomeknown to any user.

The generated authentication data may be stored in a user accessiblememory, such as a hard drive of a computer device, or on a removablememory such as a floppy disk or a flash memory. As mentioned above, theauthentication data need to be protected from any user, especially froma malicious user. Thereto, the authentication data are encrypted by theauthentication software, preferably running in a secure processingenvironment, before the authentication data are stored in said useraccessible memory.

According to cell 210, the authentication data are encrypted by a firstencryption layer, e.g. by an encryption algorithm which is part of theauthentication software package. The algorithm is secured such that itdoes not become known to any user. According to cell 212, theauthentication data are further encrypted by a second encryption layer,e.g. using an encryption key which is associated with a hardware deviceserial number, or the like, thereby preventing illegal copying toanother device. If the authentication data are stored in a removablememory, for example a flash memory, the encryption key may be associatedwith a serial number of the removable memory. Preferably, the encryptionkey is (also) associated with a user identifying number, e.g. a personalidentifying number (PIN) or a number or a template associated with afingerprint of the user, or the like.

According to cell 214, the encrypted authentication data are stored inthe memory. Thus, the device is provided with the authenticationsoftware and the authentication data, the authentication data beingsecured by encryption from becoming known to a user. The device isinstalled for performing the transaction method and the legitimate useverification method according to the present invention.

FIG. 5A illustrates schematically an embodiment of an electronic devicefor performing the installation method according to the third embodimentof the present invention. The schematic diagram of FIG. 5A is similar tothe diagram of FIG. 3. The illustrated electronic device compriseshardware 42, a BIOS 44, an operating system 48, a user application 50,and a console 52. From the below description, it will become apparent tothose skilled in the art that the secure area 62 (as indicated in FIG.3) is not essential for performing the third embodiment of theinstallation method according to the present invention.

After installation of the authentication software package according tothe method illustrated in FIG. 4, an encrypted data package is stored ina memory location 63 that is a part of the hardware 42. The memorylocation 64 is accessible to a user via a user application 50. Theapplication 50 may request data from the memory location 63 by sending arequest to the operating system 48. The operating system 48 may obtainthe data stored at the memory location 63 possibly via the BIOS 44. Theauthentication software is also installed and stored in a useraccessible memory location as indicated. The authentication software maybe encrypted, or not.

The data stored at the memory location 63 are encrypted authenticationdata. The encryption of the authentication data renders the dataunusable to the user application 50. FIG. 5B illustrates the encryptionof authentication data 63A stored in memory location 63. Theauthentication data 63A are encrypted twice as illustrated in FIG. 4. Afirst encryption layer 63B and a second encryption layer 63C protect theauthentication data 63A. Said encryption layers 63B and 63C may beremoved by decryption by the corresponding application.

One encryption layer may be decrypted by the authentication software 54.The other encryption layer may be an encryption/decryption applicationstored in the electronic device using a device specific encryption key.Such an application may be stored in the BIOS or in a secure area 58 (asindicated in FIG. 3) and may use the encryption key 46. In otherembodiments, there may be only one encryption layer or any otherencryption/decryption application may be employed.

Referring to FIG. 5A again, the application 50 may require a digitalsignature for an electronic transaction or for verification oflegitimate use of digital data. Thereto, the authentication software 54is executed to initiate decryption of the authentication data stored inmemory location 63 and for generating said digital signature. From oneauthentication table, numerous digital signs may be generated. FIG. 6illustrates a method to generate a certain digital signature from anauthentication table and illustrates how numerous different digitalsigns may be generated. Using different digital signs for every actionminimizes the chance of infringements or forgery and maximizes theability to trace the origin of an illegal copy.

FIG. 6 shows two actors, a BIOS and the authentication software. Theauthentication software starts by collecting data according to cell 64.There are multiple components required. First a fixed component, whichis identical for each instance a digital signature is generated.Further, a variable component is used, which enables the method togenerate a numerous amount of different, but traceable digital signs. Asystem trace component, e.g. a transaction ID, also depends on theinstance. Two variable components make it virtually impossible to derivethe authentication table from a number of generated digital signs.Optionally, a personal identification number (PIN) or password may beused to identify the user as well as the device in which theauthentication software is embedded.

When all the required data is collected, the authentication softwarehashes the collected data into a bit string and translates the bitstring into a number of pointers according to cell 66. Using theencryption key, the authentication table is decrypted by the BIOSaccording to cell 68. The pointers generated according to cell 66 pointto positions in the authentication table. Using the pointers, theauthentication software gathers a series of random numbers from theauthentication table according to cell 70. Thereafter, according to cell72, the BIOS encrypts the authentication table again. Finally, thedigital signature accompanied by the variable data components that wereused to generate the digital signature are transferred to the requestingapplication according to cell 74.

A digital signature generated according to the present invention may beused in various ways. First, it may be used to track and trace digitalfiles. Second, it may be used off-line to prevent illegally copiedsoftware from being used and third, the digital signature may be used inon-line transactions and authentication, for example network accessauthentication.

FIG. 7 illustrates the track and trace method for digital files.Information contained in a digital file may be protected by copyrights,for example. Software, films or music may be bought and downloaded fromthe Internet. However, such digital files containing protectedinformation may be very easily illegally copied and spread without atrace of whom copied and spread the file. Adding a trace in the digitalfile makes it possible to trace to origin of the illegal copy. Rightfulowners of such a digital file, e.g. music file, will therefore notspread the file, but they may use the file on different locations, forinstance on their computer at home and on their portable digital player,e.g. MP3-player.

According to cell 80, a third party application receives a request for adigital file, e.g. software or a music file. The third party applicationis intended to provide protected or traceable digital files and may beany application adapted therefor. It may be an on-line application, forexample.

Then, according to cell 82, the third party application asks therequesting device if the authentication software is installed andrunning. According to cell 84, the BIOS responds. If the authenticationsoftware is not installed or running, the device is rerouted to atrusted third party to download and install the software according tocell 24 of FIG. 2.

If the software is installed and running, the third party applicationstarts the transaction by transferring a transaction ID to therequesting device's BIOS according to cell 86. According to cell 88, theBIOS and authentication software generate a digital signature inaccordance with the method described in relation to FIG. 6 using thetransaction ID they received.

The generated digital signature together with the variable datacomponent, e.g. date/time, is then sent to the third party application.According to cell 90, the third party application stores the digitalsignature, the variable data component, transaction ID, which itprovided itself, and some data that identifies the requesting device,e.g. an IP-number, Ethernet number, serial number or any other uniqueidentifying number, in a database.

Further, the digital signature is embedded in the requested digital fileaccording to cell 92. This does not necessarily need to be conductedafter the storage according to cell 90, but may also be done before orat the same time.

The digital signature is preferably unique for the requested digitalfile. When an illegal copy of the digital file is found, the third partyapplication will be able to check in its database to which device itsent that particular file after reading the digital signature embeddedin the file.

The file with the digital signature embedded therein is sent to therequesting device according to cell 94, which completes the method.

In a further embodiment, the authentication software may be providedwith a system for signing a digital signature according to the presentinvention using at least a part of a software identification number(software ID) or any other application identifying character string,hereinafter referred to as a private key. The private key is registeredat a third party, for example the authentication software provider whichsupplied said private key. The private key may be used to uniquely signthe digital signature and append the signed digital signature to thedigital signature, which is sent to the second transaction party; Thesecond transaction party is not capable of generating the signed digitalsignature without the private key. The second transaction party onlystores the signed digital signature.

The first transaction party may later claim not to have performed thetransaction and not to have generated the digital signature, and maythus claim that another party has maliciously presented itself as thefirst transaction party while being able to generate a correspondingdigital signature. The second transaction party may then verify thesigned digital signature by sending it to the third party, which mayverify the signed digital signature. Based on the signed digitalsignature it may be determined whether a malicious user has performedthe transaction or the first transaction party is maliciously claimingnot to have performed the transaction.

FIG. 8 illustrates a method to protect digital files from being used onother devices than the originally intended device. For illustrativepurposes, an application that is digitally signed according to thepresent invention is described in relation to FIG. 6. However, themethod may also be used for any other signed digital file such as a filecontaining music or video.

According to cell 100, an application having a digital signatureembedded therein is being started on a device having the authenticationsoftware installed in its BIOS. The embedded digital signature has beengenerated on said device and is therefore device specific. For example,the application may have been obtained using the method discussed inrelation to FIG. 7. In any case, the application has been signed andprogrammed to be used on the specific device having the authenticationsoftware installed.

The application is programmed to start with a verification of itsembedded digital signature. Therefor, the application requests the BIOSto verify its digital signature according to cell 102. For the BIOS tobe able to verify the digital signature, it needs the data componentsthat were used to generate the digital signature. So, according to cell104, the application transfers the data components to the BIOS. Afterreceipt of all necessary data from the application, the BIOS regeneratesthe digital signature according to cell 106.

For verification, it is needed to compare the embedded digital signaturewith the regenerated digital signature. This comparison may be conductedby the authentication software in the BIOS or the BIOS. Thus, accordingto cell 108, the BIOS receives and compares the embedded digitalsignature with the regenerated digital signature.

If the two digital signs are identical, the application starts accordingto cell 110, otherwise the BIOS prevents the application being started,possibly informing the user that it is trying to use an illegal copy ofthe application.

FIG. 9 illustrates an on-line transaction method. An on-line applicationis accessed with a request for a transaction, possibly a financialtransaction. For example, the transaction may be a customer who wishesto purchase an item on-line. Usually, such transactions are performedusing a credit card. However, only a credit card number and someadditional data are supplied by the customer. If a customer later stateshe did not purchase or use his credit card, there is no way of verifyingby checking a signature, like in common credit card transactions.

Referring to FIG. 9, according to cell 120, the on-line applicationreceives a request for a transaction. Upon this request, the on-lineapplication asks the BIOS of the requesting device if the authenticationsoftware according to the present invention is installed and running. Ifnot, the requesting device is rerouted to a TTP to download and installthe authentication software and authentication table according to themethod discussed in relation to FIG. 2 or FIG. 4.

If the authentication software is installed and running, the BIOSresponds accordingly according to cell 124 and the on-line applicationhands over a transaction ID according to cell 126. The requesting devicemay then generate a digital signature according to the method describedin relation to FIG. 6, according to cell 128. The variable datacomponents used for generating the digital signature and the digitalsignature itself are then transferred to the on-line application, whichmay then complete the transaction according to cell 130.

The digital signature functions as a signature in this case. If thecustomer later claims not to have used its credit card, for example, theon-line application owner may verify the digital signature. Theverification of the digital signature may be conducted by the trustedthird party, which supplied the authentication table to the customer andis able to regenerate said authentication table. It may also beconducted by using the customer device regenerating a digital signatureusing the variable data components stored by the on-line application.

Optionally, a certain on-line third party application may use anauthentication table in transactions with a specific device, whichauthentication table is specifically intended for use in transactionswith said certain on-line third party application. Such a specificauthentication table has the advantage that the third party applicationmay verify the digital signature already before completing thetransactions and so preventing that problems may later arise.

The specific authentication table may be derived from the authenticationtable stored in the BIOS of said device using an algorithm known to thedevice. The specific authentication table derived from the originalauthentication table would then be supplied by the TTP to the on-lineapplication. Thus, the device knows how to derive the specificauthentication table and the on-line third party application knows acertain table, but not the original table stored in the BIOS of thedevice. Otherwise, the on-line third party may provide a separateauthentication table to the requesting device. The specificauthentication table is encrypted before it is stored using a BIOSspecific encryption key. This ensures that the supplying third partydoes not know the stored authentication data and therefore the thirdparty can not use the data in a fraudulent way.

If the on-line application knows the authentication table used by therequesting device to generate a digital signature, the requesting devicemay be a device connecting to a network, e.g. a corporate privatenetwork. The requesting device needs to be identified by the corporatenetwork before access to the corporate network is granted. Uponconnection, the requesting device sends a digital signature that wasgenerated using fixed data components and variable data components. Thefixed data components may comprise a password or a personalidentification number (PIN). The fixed data components are known to thecorporate network and do not need be sent over the unsecured networkconnection; only the variable data components used are sent over theunsecured connection. Thus, the corporate network may regenerate thedigital signature of the connecting device after receipt of the usedvariable data components. This method has the advantage that no passwordor PIN is sent over an unsecured connection and that the digitalsignature identifies both the device (authentication table) and the user(PIN or password).

Apart from securing a transaction or network authentication asillustrated above, also the hardware used in the operating environmentmay be verified. For example, if a first computer communicates with asecond computer, the second computer may identify itself in a similarway, using similar data, as used in a transaction, described above. Ifthe authentication table of the second computer is known at the firstcomputer, the identification of the second computer may be verified bythe first computer. A similar procedure is feasible when one of thecomputers communicates with a printer, as long as the authenticationtables are stored securely in the devices.

FIG. 10 illustrates a method for authenticating a user to access digitaldata that are stored in a removable and portable memory such as a flashmemory. Digital data may be stored in the removable memory using theencryption method for protecting (authentication) data as illustrated inand described in relation to FIG. 4, i.e. data are encrypted using atleast one, preferably at least two encryption layers, of which one layeris related to the authentication software installed according to FIG. 4.The removable memory is to be connected with an electronic device onwhich the authentication software has been installed according to saidmethod illustrated in FIG. 4 in order to decrypt the encryption layerrelated to said authentication software.

Referring to FIG. 10, digital data are stored in a removable andportable memory. The digital data are encrypted on another electronicdevice, for example a computer device at work, while the electronicdevice attempting to access the digital data is a computer device athome.

The authentication software for accessing the digital data is installedon both computer devices, e.g. at home and at work, according to theinstallation method of FIG. 4. The digital data are to be read by a userapplication such as a text editor, a spreadsheet application, an audioor video application, or the like. In another case, the digital data maybe a software application to be executed by the electronic device.

After connecting the portable and removable memory with the electronicdevice, a user starts the user application. From the user application,an attempt is made to access the digital data according to cell 220. Thedigital data are however encrypted.

Then, according to cell 222, the authentication software is started todecrypt the digital data. The digital data are transferred to theauthentication software. In accordance with cell 224, the authenticationsoftware decrypts a first encryption layer using a decryption algorithm,for example embedded in the authentication software. Said decryptionalgorithm is identical on each device that is provided with theauthentication software.

To prevent that any device being provided with the authenticationsoftware may decrypt the digital data, the digital data may be protectedwith a second encryption layer. For decryption of the second encryptionlayer, a decryption key is required. Such a decryption key may beassociated with a serial number of the portable memory, ensuring thatthe digital data are only decryptable if the digital data are stored insaid portable memory. A copy of the digital data in any other memory isthereby rendered undecryptable. Likewise, the decryption key may beassociated with a personal identification number (PIN) rendering thedigital data unusable without the PIN. In yet another embodiment, thedecryption key may be associated with a fingerprint of a user, renderingthe digital data unusable without the presence of that specific user.

The decryption key may be associated with any identifying characteristicsuch as a serial number, a PIN or a fingerprint by a protected hashingalgorithm or it may be identical to the serial number or PIN. Hashingthe characteristic provides however an additional security layer,especially when the hashing is performed in the secure processingenvironment.

According to cell 226, the data for generating the decryption key arecollected and the decryption key is generated. Then, in accordance withcell 228, the second encryption layer is decrypted. The digital data arenow suitable for access by the user application. Therefore, in cell 230,the digital data are provided to the user application and in cell 232,the user application accesses and uses the digital data. After use andpossibly alteration of the digital data, the digital data are againstored in the removable memory using the encryption algorithm of theauthentication software and using the decryption key used to access thedigital data.

Above it is described that the decryption algorithm is identical on eachdevice that is provided with the authentication software. However, thedecryption/encryption algorithm may also be different for each device orit may be identical for each device that is installed using anauthentication software package obtained by a specific user. Thus, thedigital data may only be accessible on a device that is previouslyinstalled by said specific user.

In such a case, it is necessary to provide certain authentication datato the transaction party supplying said authentication software, sincethe user specific algorithm needs to be embedded in the software packagebefore the software package is supplied to the specific user in order toprotect the algorithm.

In an even further embodiment, digital data may be encrypted using anencryption key that is generated according to the present invention,i.e. identical to the method for generating a digital signature. FIG. 6illustrates how a digital signature may be generated according to thepresent invention by gathering session specific data, such as fixeddata, variable data, personal data and/or device specific data. Hashingsaid session specific data may generate reference numbers, referring topositions in the authorization table securely stored according to thepresent invention. Gathering the characters stored in the authorizationtable at said positions generates a bit string comprising a number ofcharacters. Said bit string may comprise any number of characters andsaid number may be dependent on the session specific data. Dataencrypted with an encryption key having an unknown number of bits isvirtually impossible to be cracked by another person not entitled toaccess said data.

To decrypt the data, the encryption key is required. To obtain theencryption key, the authorization table and the session specific dataare needed. Having an authorization table stored and installed in adevice according to the present invention, data may be securely storedin a memory of said device. The data may easily be decrypted when beingaccessed using said device. However, a copy of said encrypted data onany other device is rendered virtually inaccessible.

If identical authorization tables are stored on two or more separatedevices, encrypted data may be exchanged between said two or moredevices. If the encrypted data are transferred from one device toanother, together with the session specific data, the other device mayregenerate the encryption key and decrypt the data. Such an encryptionand decryption method is especially useful for secure communicationbetween said two or more devices over a publicly accessible network suchas the Internet.

In an embodiment, a network server is provided with all authorizationtables of client devices connected to said server. A client attemptingto access the server and the network of said server is authenticated byits digital signature, and thereafter all exchanged data may beencrypted using a digital signature. If a client sends data to anotherclient, the data may be encrypted and transferred to the server togetherwith the session specific data. The server decrypts the data using thesession specific data and the authorization table of the first client.Then, the server encrypts the data again, now using the authorizationtable of the other client using the same or other session specific data.Next, the encrypted data are transferred to the other client togetherwith the corresponding session specific data, which decrypts the datausing its authorization table.

Now referring to FIG. 10 again, the digital data securely stored on theportable and removable memory device may be an authorization tableaccording to the present invention. Thus, digital data encrypted usingthe authorization table may be decrypted on any device when the portableand removable memory device is connected to said device and said deviceis provided with the authorization software according to FIG. 10.

1. A method for performing an electronic transaction between a firsttransaction party and a second transaction party using an electronicdevice operated by the first transaction party, the electronic devicehaving an operating system creating a run-time environment for userapplications, the electronic device comprising a system for accessing amemory location in a memory connected to the electronic device, themethod comprising: providing a private key in said memory of saidelectronic device, said memory being any secure location in saidelectronic device, which private key is inaccessible to a user of saidelectronic device, wherein the private key is encrypted when the privatekey is stored in said memory, a decryption key for decrypting theprivate key being incorporated in the electronic device, said decryptionkey being inaccessible to said user, to any user-operated software andto said operating system, wherein said memory is inaccessible to saidoperating system of said electronic device, thereby rendering theprivate key inaccessible to said user, wherein the private key isdecrypted in a secure processing environment inaccessible to said userand to any user-operated software; providing authentication software insaid electronic device, the private key being accessible to saidauthentication software, wherein authentication software is stored insaid secure memory inaccessible to said operating system; activating theauthentication software to generate a digital signature from the privatekey, wherein the authentication software is run in a secure processingenvironment inaccessible to said operating system; providing the digitalsignature to the second transaction party.
 2. The method according toclaim 1, wherein the private key is provided by the second transactionparty, which stores the private key together with data identifying thefirst transaction party.
 3. The method according to claim 1, wherein theauthentication software has its own unique serial number, software ID orencryption key.
 4. The method according to claim 1, wherein the privatekey is encrypted by the second transaction party using an encryption keybefore the private key is provided to the first transaction party. 5.The method according to claim 4, wherein the authentication softwareretrieves a decryption key associated with the encryption key anddecrypts the private key at its first use.
 6. The method according toclaim 1, wherein the authentication software is installed in anapplication environment in the secure memory such that it may obtain theprivate key without passing through an unsecured part of said electronicdevice.
 7. The method according to claim 1, wherein the private key isencrypted using at least two encryption layers.
 8. The method accordingto claim 1, wherein the private key is encrypted using an encryption keywhich is associated with a hardware device serial number.
 9. The methodaccording to claim 1, wherein the private key is encrypted using anencryption key which is associated with a user identifying number, inparticular a personal identifying number, PIN, or a number or a templateassociated with a fingerprint of the user.
 10. The method according toclaim 1, wherein the decryption key is associated with one or moreserial numbers of hardware components of said electronic device.
 11. Themethod according to claim 1, wherein the private key is decrypted by theauthentication software.
 12. The method according to claim 1, whereinthe private key is decrypted by an application stored in the electronicdevice using a device specific encryption key.
 13. The method accordingto claim 1, wherein the private key is decrypted using a decryption keyassociated with any identifying characteristic, in particular a serialnumber, a personal identification number, PIN, or a fingerprint of auser.
 14. The method according to claim 1, further comprisingidentifying the user of the electronic device before activating theauthentication software.
 15. The method according to claim 1, whereinthe authentication software has an encryption key for encrypting digitaldata.
 16. An electronic device comprising a network interface configuredfor an electronic transaction between a first transaction party, and asecond transaction party, wherein the electronic device is operated bythe first transaction party; a processor configured for an operatingsystem creating a run-time environment for user applications; a memorystoring a private key, said memory being any secure location in saidelectronic device, which private key is inaccessible to a user of theelectronic device, wherein the private key is encrypted when the privatekey is stored in said memory, a decryption key for decrypting theprivate key being incorporated in the electronic device, said decryptionkey being inaccessible to said user, to any user-operated software andto said operating system, wherein said memory is inaccessible to saidoperating system of said electronic device, thereby rendering theprivate key inaccessible to said user, wherein the private key isdecrypted in a secure processing environment inaccessible to said userand to any user-operated software; and a memory storing authenticationsoftware, the private key being accessible to said authenticationsoftware, wherein the authentication software is stored in a securememory location inaccessible to said operating system; wherein theprocessor is configured for activating the authentication software togenerate a digital signature from the private key, wherein theauthentication software is run in a secure processing environmentinaccessible to said operating system, for providing the digitalsignature to the second transaction party.
 17. Method for performing anelectronic transaction between a first transaction party and a secondtransaction party using an electronic device operated by the firsttransaction party, the electronic device having an operating systemcreating a run-time environment for user applications, the methodcomprising: providing a private key in a memory of said electronicdevice, wherein the private key is encrypted, when the private key isstored in said memory, a decryption key for decrypting the private keybeing incorporated in the electronic device, said decryption key beinginaccessible to said user, to any user-operated software, and to saidoperating system, wherein the private key is decrypted in a secureprocessing environment inaccessible to said user and to anyuser-operated software; providing authentication software in saidelectronic device, the private key being accessible to saidauthentication software; activating the authentication software togenerate a digital signature from the private key, wherein theauthentication software is run in a secure processing environmentinaccessible to said operating system; providing the digital signatureto the second transaction party.
 18. An electronic device comprising anetwork interface configured for an electronic transaction between afirst transaction party, and a second transaction party, wherein theelectronic device is operated by the first transaction party; aprocessor configured for an operating system creating a run-timeenvironment for user applications; a memory storing a private key,wherein the private key is encrypted, when the private key is stored insaid memory, a decryption key for decrypting the private key beingincorporated in the electronic device, said decryption key beinginaccessible to said user, to any user-operated software, and to saidoperating system, wherein the private key is decrypted in a secureprocessing environment inaccessible to said user and to anyuser-operated software; and a memory storing authentication software,the private key being accessible to said authentication software;wherein the processor is configured for activating the authenticationsoftware to generate a digital signature from the private key, whereinthe authentication software is run in a secure processing environmentinaccessible to said operating system, for providing the digitalsignature to the second transaction party.
 19. The electronic deviceaccording to claim 18, wherein the electronic device is a personalcomputer, a cellular phone, a hand-held personal digital assistant withwireless communication capabilities, or a device comprising a system foraccessing a memory location in a memory connected to the electronicdevice.